home *** CD-ROM | disk | FTP | other *** search
/ Mac Expert 1995 Winter / Mac Expert - Winter 95.iso / Les fichiers / Utilitaires divers / Images / PhotoExchange 1.0 ƒ / Article PhotoCD Toolkit / Article PhotoCD Toolkit.rsrc / TEXT_128.txt < prev    next >
Encoding:
Text File  |  1992-10-23  |  12.8 KB  |  99 lines
  1.  
  2. KODAK PHOTO CD ACCESS DEVELOPER TOOLKIT 1.3
  3.  
  4. PROGRAMMER L‚ÄôACCES AUX PHOTO CD
  5.  
  6. Par Rodolphe DURAND
  7.  
  8. Le Photo CD Toolkit est une biblioth√®que de routines, ou API, propos√©e par Kodak aux d√©veloppeurs, afin de leur faciliter  l‚Äôacc√®s aux images PCD. Gr√¢ce √† lui, rien de plus simple que de  lire ce format de fichier tr√®s particulier.
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32. Choix de la r√©solution
  33.  
  34.  
  35.  
  36. A peine sortie la premi√®re version du Photo CD Toolkit (d√©but  ao√ªt) et Kodak fait d√©j√† parvenir une mise √† jour. Non pas que la premi√®re API  (Application Program Interface) √©tait bugu√©e outre mesure, ce  nouveau cru se justifie surtout pour acc√©l√©rer le processus de  lecture (de 17% √† 60%) et apporter de nouvelles fonctions.
  37. Le Toolkit s'adresse aux d√©veloppeurs d√©sireux d'exploiter le Photo CD (PCD) dans  leurs applications existantes ou √† venir. Outre une documentation  anglaise, un CD de 24 images et une disquette de Headers et  librairies C (MPW et Think), le Toolkit procure surtout une  licence. Pour Kodak, le prix √† payer s'explique pour cette raison et ‚Äì  applaudissons √† deux mains ‚Äì pour le suivi du produit. Remarquons  que le lecteur de CD-ROM doit r√©pondre √† la norme XA (eXtended  Architecture) et que l'option multi-sessions (XA-2) est souhaitable, sachant qu'il est possible de faire rajouter des images  un CD Kodak d√©j√† enregistr√© (jusqu'√† 100 images au gr√© de ses  d√©veloppements de n√©gatifs).
  38. Avant de d√©crire les fonctions du Toolkit et de commenter les  r√©sultats d'une application √©crite √† l'aide de ses librairies, nous introduirons les principes de bases  du PCD.
  39.  
  40. CONTENU
  41.  
  42. D'un point de vue de qualit√©, les 24 bits par pixel sont toujours  au rendez-vous quel que soit le format, mais ne correspondent pas  au classique cube RVB. Suivant le syst√®me CIE (Commission Internationale de l'Eclairage : 1931), Kodak a  pr√©f√©r√© coder la couleur avec 2 octets en chrominance (C1 et C2)  tandis que le 3√®me en exprime l'intensit√© (24-bit YCC). Si ce  codage des couleurs diff√®re des formats habituels en  informatique (RVB), il est capable d'en exprimer une aussi grande richesse et  la conversion en RVB est de toute fa√ßon ais√©e. Le choix du YCC  n‚Äôest pas un simple caprice de constructeur. D'abord, sa  similarit√© avec les standards t√©l√©visions (YUV ou UV signifie  aussi 2 autres Chrominances) le rapproche du grand public et cette  mani√®re de stocker la luminance √† part, en fait du m√™me coup un  autre format en niveau de gris (8-bit Y). Ensuite, la vision  humaine ayant une bien meilleure acuit√© √† la luminosit√© qu'√† la  couleur, il est possible de "sous-√©chantillonner" les deux chrominances  sans perte significative lors de la restitution. C'est ce que   Kodak √† donc r√©alis√© en divisant par un facteur de 2 (lin√©aire,  donc de 2 x 2 = 4 en surface) les deux composantes de la  chrominance pour obtenir ainsi un fichier graphique directement r√©duit de  moiti√©, avant toute compression algorithmique.
  43.  
  44. CONTENANT
  45.  
  46. Le PCD recouvre deux formats. L'Overview Pac, ou fichier de  pr√©visualisation unique, contient une version compact (128x192  pixels, ouvrable aussi en 64x96) de chaque image sur le disque. Via une  indexation, il est alors possible de construire graphiquement une  directorie "d'ic√¥nes" pour laisser ensuite l'utilisateur  s√©lectionner son image pr√©f√©r√©e dans une meilleure r√©solution,  c'est √† dire l'Image Pac.
  47. Le "Pac" signifie ici un enregistrement √† de multiples  r√©solutions. Il s'agit d'un encodage pyramidale stockant telles  quelles les images de r√©solution mod√©r√©e pour un affichage  acc√©l√©r√© (128x192 appel√© Base/16, 256x384=Base/4 et 512x768=Base, destin√©s aux lecteurs ‚Äúde salon‚Äù pour TV) tandis que les  plus hautes (1024x1536=Base*4 et 2048x3072=Base*16) le sont en  diff√©rences compress√©es par rapport √† l'image de la r√©solution  juste un cran en dessous. Par exemple, ce sont des r√©siduels qui  sont cod√©s pour la Base*4, et pour la reconstituer, il faudra une  fois leurs d√©compressions effectu√©es (selon la m√©thode de  Huffman) l'extrapoler par la Base. Idem pour la Base*16 qui a  besoin de la Base*4 pour se recomposer. On comprend mieux  pourquoi on ne parle pas de JPEG, qui est une s√©rie d'algorithmes pour  compresser une image en un fichier unique, et responsable de  pertes cumul√©es chaque fois o√π le fichier r√©sultat est  recompact√©. Il s'agit ici au contraire de compresser les  r√©siduels d'une Base*n par rapport √† une base qui elle ne changera jamais, et o√π le  r√©sultat sera lui aussi toujours le m√™me.
  48.  
  49. INSIDE PCD TOOLKIT
  50.  
  51. Pour une meilleure approche, nous d√©composerons les fonctions du  Toolkit en cinq parties :
  52. - M√©moire
  53. Contr√¥ler la m√©moire quand on utilise des images de haute d√©finition est vital. Le Toolkit procure  les routines pour g√©rer celle de ses ressources. Avec un  PCDsetAllowance() par exemple, on fixera la m√©moire indispensable  pour une op√©ration adressant un gros tampon interne au Toolkit,  et une fois le traitement termin√©, la m√™me fonction lib√©rera la  place en vue d'une autre op√©ration, relative cette fois √†  l'application en elle-m√™me. A titre d'indication, la largeur d'un  block de m√©moire requis pour la lecture d'une image PCD  (PCDloadImage()) en 32-bit est de 1,5 Mo pour la Base, de 6,2 Mo pour la Base*4  et 25,1 Mo pour la Base*16. On constate ici que la Base*16 en  couleur n'est pas pour tout le monde, mais pour les  professionnels de l'image. Pour les autres, si le prix de la  barrette de 16 Mo ne baisse pas consid√©rablement, il faudra se contenter du  Base*16 (peu habituel il est vrai) en niveaux de gris.
  54. - Pr√©visualisation/Lecture
  55.  Qu'il s'agit du fichier OverView ou Image, les routines les  adressant sont relativement similaires. Par exemple, outre l'orthographe voisine entre le PCDOopen() de l'OverView Pac  et le PCDopen() de l'Image Pac, les param√®tres pass√©s sont  exactement les m√™mes. Il en est ainsi pour les fonctions qui  r√©gissent le format couleur (RVB, YCC ou niveaux de gris), qui  √©tablissent la r√©solution, qui appliquent des transformations de miroir  ou de rotation et enfin celles qui chargent les images en  m√©moire. Le Toolkit nous propose ici deux moyens pour lire le  PCD. La routine PCDloadImage() (apr√®s avoir sp√©cifi√© la  r√©solution, la d√©finition, ...) lit directement dans l'environnement 32-bit  QuickDraw ou dans un "cgrafPort", ce qui est la solution la plus  avantageuse pour afficher une image avec un minimum de code via  un CopyBits(). D'un autre c√¥t√©, PCDgetBlock() lit le format tel  quel dans un tampon arbitraire, ce qui peut-√™tre pr√©f√©rable en vue  de conversions, de manipulation intensive dans un programme ou  bien si l'on d√©sire travailler directement en YCC.
  56. Enfin, indiquons que la version 1.3 apporte de nouvelles  fonctions pour g√©rer en un seul niveau les ouvertures/fermetures de fichiers, qu'elles  soient PCD ou non. Apr√®s un FSOpen() de la Toolbox du Macintosh,  un PCDrefOpen() cr√©era ainsi toute la stucture sp√©cifique au  Toolkit (FSOpen+PCDrefOpen=PCDopen). Inversement, la fonction PCDrefClose la d√©truira en laissant le soin √† l'application de  fermer le fichier PCD.
  57. - Conversion
  58. Le Toolkit procure deux fonctions de conversion qui utilise en  entr√©e le format 24-bit YCC. PCDYCCtoRGB() donne le m√™me r√©sultat  qu'une image obtenue avec un PCDloadImage() (RVB corrig√© avec un gamma de 2,2) et PCDdither()  converti en une image niveau de gris "dithered" d'un bit par  pixel. Pr√©cisons, depuis la nouvelle version, que  "l"adoucissement" est automatique (par d√©faut, ou non par choix)  pour le chargement ou l'exportation d'images d√©sir√©es √† une d√©finition inf√©rieure  √† 16 bits/pixel (lissage des transitions entre r√©gions de  diff√©rentes couleurs pour une apparence plus naturel).
  59. - Exportation
  60. Une fois l'image ouverte par un PCDopen(), il s'agit de cr√©er un fichier Macintosh, d'y ouvrir son DataFork et d'utiliser enfin  PCDexport() pour obtenir du PICT, TIFF ou de l'EPSF. De par ses  param√®tres et outre le format d'export voulu, cette fonction  permet de fixer :  la profondeur du pixel (de 1 √† 32, sachant que  les d√©finitions inf√©rieures √† 16 ont besoin d'une table de  translation couleur via un GetCTable, idem avec un PCDloadImage),  la partie de l'image √† exporter (ou sa totalit√©) et de d√©finir le  type de pixel voulu. "Interleaved", le plus courant, o√π les 3  composants (RVB) de chaque pixel sont stock√©s en un block continu et  "Planar" en vue d'une s√©paration des couleurs et chaque √©l√©ment  est cette fois rassembl√© avec ses voisins dans un plan.
  61. - Copyright
  62. Oui, il y a un sous-directory appel√© "RIGHTS", qui contient des fichiers texte d√©crivant les copyrights o√π les restrictions  d'utilisations pour une ou plusieurs images. La fonction  PCDreadImageInfo() n'est pas l√† innocemment, et Kodak encourage  fortement son utilisation avant l'affichage de n'importe quelle  image. Mieux, il pr√©cise que l'absence d'un tel fichier relatif √† une  image ne signifie pas que celle-ci n'est pas prot√©g√©e. Attention  aux rois du photomontage !
  63.  
  64. PHOTO-EXCHANGE : L'APPLICATION
  65.  
  66. S'inspirant de l'exemple de visualisation des images PCD fournit  dans le Toolkit, nous avons rajout√© le source n√©cessaire (conforme  syst√®me 7) pour impl√©menter les fonctions d'exportations en PICT,  TIFF et EPSF. A l'issue de quelques compilations de Think C 5.0.2  et de grandes b√©n√©dictions √† ResEdit 2.1.1, nous voil√† partis √† l'exploration des images du CD-ROM. Apr√®s de longues  tergiversations, nous avons choisi finalement le profil droit  d'une pertinente petite fille joliment maquill√©e et les tests ont  enfin pu commencer (Pr√©cisons, pour r√©f√©rence, que nous avons  transf√©r√© le contenu du CD-ROM sur le disque dur interne de la machine  pour de meilleurs temps d'acc√®s disque et que la machine en  question est un Quadra 900 de 36 Mo de m√©moire vive - 26 Mo sont  n√©cessaires pour adresser du Base*16 en 32-bit, voir paragraphe  m√©moire). Premi√®res constatations, si le temps d'affichage est  n√©gligeable pour une image haute en couleur ne d√©passant pas la  Base, il  lui faut 38 secondes sur un Quadra 900 en Base*4  (presque 1 mn avec la 1√®re version) et l√©g√®rement plus de 3  minutes en Base*16  (presque 5 mn avec la 1√®re version). Il est vrai qu'il  s'agit ici de 1,10 m√®tre sur 72 centim√®tres, ce qui ne correspond  pas vraiment √† l'applicatif de tous les jours. Notons aussi √†  titre de comparaison, que PhotoShop, √† partir d'un fichier PICT  et sans effectuer de d√©codage, ouvre cette dimension en un peu  moins de 3 minutes. Passons maintenant √† l'exportation et restons  gourmand en Base*16 24-bit pour demander un fichier PICT.  R√©sultat : 18 Mo sont g√©n√©r√©s √† partir du fichier de 3,9 Mo de  notre petite fille. Ce n'est pas mal contenu du fait que ces 3,9 Mo sont  relatifs de 5 r√©solutions diff√©rentes. On reste dans le m√™me  ordre de grandeur avec du TIFF mais surprise, le fichier EPSF  g√©n√©r√© n'est pas reconnu par PhotoShop. Apr√®s plusieurs  tentatives infructueuses de chargement dans divers softs graphiques,  FrameMaker arrive finalement √† le charger sous la forme d'une  boite toute grise mais signale des erreurs PostScripts d√®s que  l'on veut l'imprimer. Enfin, personne n'est parfait, et gageons  que Kodak s'occupe d√©j√† de ce probl√®me. Pour finir, nous dirons qu'il a √©t√©  plut√¥t agr√©able de d√©velopper notre logiciel, PhotoExchange.  L‚Äôhomog√©n√©it√© des fonctions du Toolkit font que le programmeur  n'a m√™me pas besoin de comprendre la fa√ßon dont sont stock√©es les  images, ou de se lancer corps et √¢me dans le d√©chiffrage de l'une  de ses structures.
  67.  
  68. Le PCD Toolkit r√©pond clairement aux besoins d'un d√©veloppeur de  logiciels et celui-ci aura vite compris que Kodak fait figure  d'une sacr√©e locomotive dans le domaine de l'image num√©rique. Il est en effet le seul √† placer la qualit√©  chimique de la photographie dans une expression num√©rique  accessible √† tous (4 Frs la photo CD) et √† n'importe quel type de  besoins (QuickTime, TV, TVHD, format publicitaire, ...). Une  nouvelle version serait pourtant encore la bienvenue, moins pour les plus  paresseux ne disposant pas de leur propre fonction d'export EPSF,  mais surtout pour sauvegarder tout simplement en format PCD. Si  ce format est en voie de standardisation, et bien qu'un r√©seau mondial d'acc√®s √† des millions d'images PCD est en train de se   mettre en place, les flasheurs, pour ne citer qu'eux, aimeraient  s√ªrement se servir de leurs propres scanners afin de l'utiliser  et de l'√©changer. Esp√©rons alors que la sortie des nouveaux formats PCD et notamment le PCD-Master-Pro int√©grant la Base*32  co√Øncidera avec celle du Photo CD Toolkit 2.O.
  69.  
  70. KODAK PHOTO CD ACCESS DEVELOPER TOOLKIT 1.3
  71. FONCTION : Licence et Kit d'exploitation du PCD dans une  application.
  72. DISTRIBUTEUR : Images Informations Services
  73. 3, Chemin de la Jonch√®re
  74. B.P. 24
  75. 92502 Rueil-Malmaison
  76. T√©l. : 47 32 02 68
  77. PRIX : 6 950 F HT
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97. Option PICT, TIFF et EPSF pour l'export.
  98.  
  99.